Methods, computer systems, and physical computer storage media for managing resources of a storage server

ABSTRACT

For managing a storage server having improving overall system performance, a first input/output (I/O) request is received. A first priority level is dynamically assigned to the first I/O request, the first I/O request associated with a performance level for an application residing on a host in communication with the storage server. A second I/O request of a second priority level is throttled to allow at least a portion of a predetermined amount of resources previously designated for performing the second I/O request to be re-allocated to performing the first I/O request. The second priority level is different than the first priority level.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to storage servers, and moreparticularly, to methods, computer systems, and physical computerstorage media for managing resources of storage servers.

2. Description of the Related Art

Data processing systems can have many nodes that are geographicallydispersed. In such case, the systems can be managed in a distributedmanner by logically separating each environment into a series of looselyconnected managed regions. Each environment can have a management serverfor managing local resources, while a management system includingmanagement servers coordinate activities across the system to permitremote site management and operation. In this way, local resourceswithin one region can be exported for the use of other regions. Themanagement system can be governed by a service level agreement providingrules for managing the many systems.

In order to fulfill quality-of-service guarantees delineated by theservice level agreement within a network management system, performancemeasurements may be required along various network routes throughout thesystem. In particular, the management system measures resourceconsumption while an application is running. Measurements are takenalong particular routes and metrics and descriptions relating tooperations performed consuming bandwidth are accumulated.

SUMMARY OF THE INVENTION

Different applications may have different quality-of-servicerequirements delineated by the service level agreement. For instance,some applications may require a faster response time and/or higherinput/output throughput than other applications. In other cases, anapplication may require larger bandwidth or larger storage capacity thananother application. In the past, lower priority input/output (IO)requests were throttled based on static mapping between storagerequirements and storage service classes of an application. As a result,in some instances, lower priority IO requests would be neglected infavor of high priority IO requests, and the system would becomeoverloaded by the volume of high priority IO requests in a queue.Consequently, system operation was not as efficient as desired and lowpriority request would be minimally fulfilled. To optimize overallperformance of the system, improved methods and systems for managingstorage media are needed.

One improved method dynamically assigns priorities to IO requests basedon the performance level and importance of the host application whichthe IO requests belong to, and throttling lower priority IO requestsbased on 1) a performance level of the high priority IO requestscompared with a performance level of the lower priority requests, and 2)relative performance level of the high priority IO requests comparedwith its performance target, which is defined within the storage classto which the high priority IO requests is currently mapped. In anembodiment, by way of example only, a first IO request is received.Then, a first priority level is dynamically assigned to the first IOrequest, where the first IO request is associated with a performancelevel for an application residing on a host in communication with thestorage server. A second IO request of a second priority level isthrottled, when the performance level of the first IO request does notmeet or exceed a first target to allow at least a portion of apredetermined amount of resources previously designated for performingthe second IO request to be re-allocated to performing the first IOrequest, where the second priority level is different than the firstpriority level.

In another embodiment, by way of example only, a computer system isprovided. The computer system includes a host and a storage server. Thehost is configured to provide input/output (IO) requests. The storageserver is in communication with the host and is configured to receivethe IO requests. The storage server includes a processor configured toreceive a first input/output (IO), to dynamically assign a firstpriority level to the first IO request, the first IO request having aperformance level, and to throttle a second IO request of a secondpriority level, when the performance level of the first IO request doesnot meet or exceed a first target to allow at least a portion of apredetermined amount of resources previously designated for performingthe second IO request to be re-allocated to performing the first IOrequest, the second priority level being different than the firstpriority level.

In still another embodiment, by way of example only, a physical computerstorage medium comprising a computer program product method for managingresources of a storage server is provided. The storage medium includescomputer code for receiving a first input/output (IO), computer code fordynamically assigning a first priority level to the first IO request,the first IO request having a performance level for an applicationresiding on a host in communication with the storage server, andcomputer code for throttling a second IO request of a second prioritylevel, when the performance level of the first IO request does not meetor exceed a first target to allow at least a portion of a predeterminedamount of resources previously designated for performing the second IOrequest to be re-allocated to performing the first IO request, thesecond priority level being different than the first priority level.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsthat are illustrated in the appended drawings. Understanding that thesedrawings depict only typical embodiments of the invention and are nottherefore to be considered to be limiting of its scope, the inventionwill be described and explained with additional specificity and detailthrough the use of the accompanying drawings, in which:

FIG. 1 is a pictorial representation of an example distributed dataprocessing system, according to an embodiment;

FIG. 2 is a block diagram of an example data processing system,according to an embodiment; and

FIG. 3 is a flow diagram of a method of managing resources of a storageserver, according to an embodiment.

DETAILED DESCRIPTION OF THE DRAWINGS

The illustrated embodiments below provide systems and methods formanaging a storage server that have improved overall system performance.The systems and methods allow dynamic adjustment of storage classes ofhigh and low priority IO requests, based on analyses of performancefeedback data associated with those IO requests. Generally, the methodincludes receiving a first input/output (IO) request, where the first IOrequest is associated with a performance level and a first prioritylevel for an application residing on a host in communication with thestorage server. A second IO request of a second priority level isthrottled, when the performance level of the first IO request does notmeet or exceed a first target to allow at least a portion of apredetermined amount of resources previously designated for performingthe second IO request to be re-allocated to performing the first IOrequest, where the second priority level is different than the firstpriority level.

With reference now to the figures and in particular with reference toFIGS. 1-2, example diagrams of data processing environments are providedin which illustrative embodiments of the present invention may beimplemented. It should be appreciated that FIGS. 1-2 are only examplesand are not intended to assert or imply any limitation with regard tothe environments in which aspects or embodiments of the presentinvention may be implemented. Many modifications to the depictedenvironments may be made without departing from the spirit and scope ofthe present invention.

With reference now to the figures, FIG. 1 depicts a pictorialrepresentation of an example distributed data processing system in whichaspects of the illustrative embodiments may be implemented. Distributeddata processing system 100 may include a network of computers in whichaspects of the illustrative embodiments may be implemented. Thedistributed data processing system 100 contains at least one network102, which is the medium used to provide communication links betweenvarious devices and computers connected together within distributed dataprocessing system 100. The network 102 may include connections, such aswire, wireless communication links, or fiber optic cables.

In the depicted example, host/server 104 and host/server 106 areconnected to network 102 along with storage server 108. One or both ofthe host/servers 104, 106 are application servers and include a storagecontroller 109, 111 that is configured to control storage and access ofdata stored on the storage server 108. In this regard, the host/servers104, 106 are configured to provide input/output (“IO”) requests to thestorage server 108. In an embodiment, the host/servers 104, 106 assignpriority levels and performance levels to the IO requests. For example,the priority level of an IO request can range from a high priority, amedium priority, or a low priority. Thus, one IO request can have ahigher or lower priority level than another IO request. As used herein,the performance level can be set at a target and can be measurednumerically or qualitatively.

Storage server 108 may be include a storage unit and can comprise anystorage system. Examples of storage server 108 may include an advancedstorage device, such as a DS8000 dual node controller, or a file server,such as a network attached storage (NAS) device. Although twohost/servers 104, 106 are shown, more or fewer can be included in otherembodiments. Distributed data processing system 100 may includeadditional servers, and other devices not shown.

In the depicted example, distributed data processing system 100 is theInternet with network 102 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, the distributed data processing system 100 may also beimplemented to include a number of different types of networks, such asfor example, an intranet, a local area network (LAN), a wide areanetwork (WAN), or the like. The illustrative embodiments are alsoparticularly well suited for implementation with networks, such as SANs,where the wires and switches utilize Fibre Channel, iSCSI, FCOCEE, orthe like technologies. As stated above, FIG. 1 is intended as anexample, not as an architectural limitation for different embodiments ofthe present invention, and therefore, the particular elements shown inFIG. 1 should not be considered limiting with regard to the environmentsin which the illustrative embodiments of the present invention may beimplemented.

With reference now to FIG. 2, a block diagram of an example dataprocessing system is shown in which aspects of the illustrativeembodiments may be implemented. Data processing system 200 is an exampleof a computer, such as host/server 104, 106 in FIG. 1, in which computerusable code or instructions implementing the processes for illustrativeembodiments of the present invention may be located.

Data processing system 200 includes a controller 209 comprising aprocessor 206, main memory 208 and, alternatively, a graphics processor210. The controller 209 supplies commands to run database and/or backupapplications to the system 200. In the depicted embodiment, the dataprocessing system 200 employs a hub architecture including north bridgeand memory controller hub (NB/MCH) 202 and south bridge and input/output(I/O) controller hub (SB/ICH) 204. Processor 206, main memory 208, andgraphics processor 210 are connected to NB/MCH 202. Graphics processor210 may be connected to NB/MCH 202 through an accelerated graphics port(AGP).

In the depicted example, local area network (LAN) adapter 212 connectsto SB/ICH 204. Audio adapter 216, keyboard and mouse adapter 220, modem222, read only memory (ROM) 224, hard disk drive (HDD) 226, CD-ROM drive230, universal serial bus (USB) ports and other communication ports 232,and PCl/PCIe devices 234 connect to SB/ICH 204 through bus 238 and bus240. PCl/PCIe devices may include, for example, Ethernet adapters,add-in cards, and PC cards for notebook computers. PCI uses a card buscontroller, while PCIe does not. ROM 224 may be, for example, a flashbasic input/output system (BIOS).

HDD 226 and CD-ROM drive 230 connect to SB/ICH 204 through bus 240. HDD226 and CD-ROM drive 230 may use, for example, an integrated driveelectronics (IDE) or serial advanced technology attachment (SATA)interface. Super I/O (SIO) device 236 may be connected to SB/ICH 204.

An operating system runs on processor 206. The operating systemcoordinates and provides control of various components within the dataprocessing system 200 in FIG. 2. As a host, the operating system may bea commercially available operating system such as Microsoft® Windows® XP(Microsoft and Windows are trademarks of Microsoft Corporation in theUnited States, other countries, or both). An object-oriented programmingsystem, such as the Java™ programming system, may run in conjunctionwith the operating system and provides calls to the operating systemfrom Java™ programs or applications executing on data processing system200 (Java is a trademark of Sun Microsystems, Inc. in the United States,other countries, or both).

As a server, data processing system 200 may be, for example, an IBM®eServer™ System p® computer system, running the Advanced InteractiveExecutive (AIX®) operating system or the LINUX® operating system(eServer, System p, and AIX are trademarks of International BusinessMachines Corporation in the United States, other countries, or bothwhile LINUX is a trademark of Linus Torvalds in the United States, othercountries, or both). Data processing system 200 may be a symmetricmultiprocessor (SMP) system including a plurality of processors inprocessor 206. Alternatively, a single processor system may be employed.Moreover, in one illustrative embodiment, the data processing system 200may be comprised of one or more System p servers with a network of hostadapters to communicate over the network 102 in FIG. 1, and a network ofRAID adapters to communicate to a plethora of storage devices.

Computer code for the operating system, the object-oriented programmingsystem, and applications or programs (such as backup applications ordatabase applications) are located on storage devices, such as HDD 226,and may be loaded into main memory 208 for execution by processor 206.The processes for illustrative embodiments of the present invention maybe performed by processor 206 using computer usable program code, whichmay be located in a memory such as, for example, main memory 208, ROM224, or in one or more peripheral devices 226 and 230, for example.

A bus system, such as bus 238 or bus 240 as shown in FIG. 2, may becomprised of one or more buses. Of course, the bus system may beimplemented using any type of communication fabric or architecture thatprovides for a transfer of data between different components or devicesattached to the fabric or architecture. A communication unit, such asmodem 222 or network adapter 212 of FIG. 2, may include one or moredevices used to transmit and receive data. A memory may be, for example,main memory 208, ROM 224, or a cache such as found in NB/MCH 202 in FIG.2.

FIG. 3 is a flow diagram of a method 300 of managing resources of astorage server, according to an embodiment. During operation of a dataprocessing system (e.g., system 100 of FIG. 1), the storage server(e.g., storage server 108) may receive an input/output (10″) request,block 302. For example, a host/server (e.g., host/server 104, 106)provides the IO request that is received by the storage server (e.g.,storage server 108). It will be appreciated that IO requests arecontinuously provided during operation of the system. Thus, IO requestsmay be provided before or after the IO request referred to in block 302.IO requests provided before the IO request referred to in block 302 maybe referred to as “previously-submitted IO requests,” and those IOrequests provided after the IO request referred to in block 302 may bereferred to as “subsequent IO requests.” A previously-submitted IOrequest may be referred to as a “first IO request,” and the IO requestreferred to in block 304 may be referred to as a “second IO request.”Additionally, the subsequent IO request can be referred to as a “thirdIO request.” It will be appreciated that the ordinal numbers referencingthe IO requests are used to illustrate when the IO requests occurrelative to each other.

At block 304, a determination is made as to whether the 10 request has ahigh priority or a low priority. For example, a calculation is made,based on a quality of service agreement, as to the priority of the IOrequest to dynamically assign a priority level to the IO request. Asnoted above, the IO request can be pre-assigned an initial prioritylevel. After the calculation is made, the priority level can change toanother priority level. In any case, when the storage server receivesthe IO request, the priority level of the IO request is provided to thestorage server. In an example, the IO request may have a priority levelthat is higher or lower than a previously-submitted IO request. Inanother example, the IO request may have a priority level that is higheror lower than a subsequent IO request.

If the priority level is high, a determination is made as to whether theIO request is being performed sufficiently, block 306. In an embodiment,the determination is made by comparing the performance of the highpriority IO request with the performance of a low priority IO request.In another embodiment, the determination is made by comparing theperformance of the high priority IO request with previous attempts toperform the high priority IO request. In any case, to make such adetermination, historical data related to the performance of the highpriority IO request and/or low priority IO request is analyzed. Forexample, analysis of the historical data includes determining whetherthe performance level of the IO request has met or exceeded a target inprevious runs of the IO request. The target can be a numerical value, inan embodiment. In another embodiment, the target can be a qualitativevalue, such as “satisfactory” or “unsatisfactory.” In other embodiments,other targets are employed.

If the IO request is not being performed sufficiently, a decision ismade to throttle a low priority IO request and a calculation is made asto how long the low priority IO request should be delayed, block 308. Inan embodiment, the storage server concurrently waits to perform the highpriority IO request, while the performance level of the high priority IOrequest does not meet or exceed the target. In another embodiment, thestorage server concurrently waits to perform the high priority IOrequest, while the performance level of the high priority IO requestcompared to the performance level of the low priority IO request doesnot meet or exceed the target. After a subsequent low priority IOrequest is identified for throttling, resources are reallocated toperforming the high priority IO request by the storage server.Specifically, at least a portion of the resources that would have beenused for performing the low priority IO request are reallocated towardsthe high priority IO request of block 308. When a determination is madeto throttle the low priority IO request, the throttled low priority IOrequest is not performed, in an embodiment. In another embodiment, thethrottled low priority IO request is performed by applying limitedresources. Consequently, the high priority IO request is performed usingre-allocated resources in proportion to the limited resources directedtowards performance of the low priority IO request. In any case, thehigh priority IO request is performed, block 310.

Returning to block 306, if the high priority IO request is beingperformed sufficiently, a determination is made as to whether resourcescan be allocated to perform the throttled low priority IO request, block312. If so, a calculation is made as to how much of the delay of thethrottled low priority IO request should be shortened or whether thedelay should be canceled for the next performance cycle, block 314. Oncecalculated, the storage server then reallocates the resources to theperformance of a subsequent the low priority IO request. The highpriority IO request is performed, block 310. In an embodiment in which adetermination is made that no resources can be allocated to perform thethrottled low priority IO request, the system continues to block 310 toperform the high priority IO request.

At block 304, if the IO request is a low priority request, the methodcontinues to block 316 to determine whether a decision had been madefrom a previous cycle to throttle low priority IO requests. If so,performance of the low priority IO request is delayed so that theresources can be allocated for the performance of thepreviously-submitted high priority IO request, block 318. For example,when the performance level of the high priority IO request does not meetor exceed a target or when the performance level of the high priority IOrequest compared to the performance level of the low priority IO requestdoes not meet or exceed a target, at least a portion of a predeterminedamount of the resources previously designated for performing thepreviously-submitted low priority IO request is re-allocated toperforming the high priority IO request. After the high priority IOrequest is performed, the low priority IO request is then performed,block 320. If at block 316, a decision had not been made to throttle lowpriority IO request, the method continues to block 320 and the lowpriority IO request is performed.

Those of ordinary skill in the art will appreciate that the hardware inFIGS. 1-2 may vary depending on the implementation. Other internalhardware or peripheral devices, such as flash memory, equivalentnon-volatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIGS. 1-2. Inaddition, although a distributed system is depicted, a single systemalternatively can be employed. In such embodiment, some of the hardware(such as the additional server) may not be included. Also, the processesof the illustrative embodiments may be applied to a multiprocessor dataprocessing system, other than the SMP system mentioned previously,without departing from the spirit and scope of the present invention.

Moreover, the data processing system 200 may take the form of any of anumber of different data processing systems including host computingdevices, server computing devices, a tablet computer, laptop computer,telephone or other communication device, a personal digital assistant(PDA), or the like. In some illustrative examples, data processingsystem 200 may be a portable computing device which is configured withflash memory to provide non-volatile memory for storing operating systemfiles and/or user-generated data, for example. Essentially, dataprocessing system 200 may be any known or later developed dataprocessing system without architectural limitation.

As will be appreciated by one of ordinary skill in the art, aspects ofthe present invention may be embodied as a system, method, or computerprogram product. Accordingly, aspects of the present invention may takethe form of an entirely hardware embodiment, an entirely softwareembodiment (including firmware, resident software, micro-code, etc.) oran embodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module,” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer-readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer-readable medium(s) may beutilized. The computer-readable medium may be a computer-readable signalmedium or a physical computer-readable storage medium. A physicalcomputer readable storage medium may be, for example, but not limitedto, an electronic, magnetic, optical, crystal, polymer, electromagnetic,infrared, or semiconductor system, apparatus, or device, or any suitablecombination of the foregoing. Examples of a physical computer-readablestorage medium include, but are not limited to, an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk,RAM, ROM, an EPROM, a Flash memory, an optical fiber, a CD-ROM, anoptical storage device, a magnetic storage device, or any suitablecombination of the foregoing. In the context of this document, acomputer-readable storage medium may be any tangible medium that cancontain, or store a program or data for use by or in connection with aninstruction execution system, apparatus, or device.

Computer code embodied on a computer-readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wired, optical fiber cable, radio frequency (RF), etc., or any suitablecombination of the foregoing. Computer code for carrying out operationsfor aspects of the present invention may be written in any staticlanguage, such as the “C” programming language or other similarprogramming language. The computer code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, or communication system, including, but notlimited to, a local area network (LAN) or a wide area network (WAN),Converged Network, or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described above with reference toflow diagrams and/or block diagrams of methods, apparatus (systems) andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flow diagrams and/or blockdiagrams, and combinations of blocks in the flow diagrams and/or blockdiagrams, can be implemented by computer program instructions. Thesecomputer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the functions/acts specified in the flow diagram and/orblock diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer, other programmabledata processing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flow diagram and/or blockdiagram block or blocks. The computer program instructions may also beloaded onto a computer, other programmable data processing apparatus, orother devices to cause a series of operational steps to be performed onthe computer, other programmable apparatus or other devices to produce acomputer implemented process such that the instructions which execute onthe computer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flow diagram and/orblock diagram block or blocks.

The flow diagrams and block diagrams in the above figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflow diagrams or block diagrams may represent a module, segment, orportion of code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flow diagrams, andcombinations of blocks in the block diagrams and/or flow diagram, can beimplemented by special purpose hardware-based systems that perform thespecified functions or acts, or combinations of special purpose hardwareand computer instructions.

1-11. (canceled)
 12. A computer system comprising: a host configured toprovide input/output (IO) requests; and a storage server incommunication with the host and configured to receive the IO requests,the storage server including a processor configured to receive a firstinput/output (IO), to dynamically assign a first priority level to thefirst IO request, the first IO request associated with a performancelevel for an application residing on a host in communication with thestorage server and to throttle a second IO request of a second prioritylevel to allow at least a portion of a predetermined amount of resourcespreviously designated for performing the second IO request to bere-allocated to performing the first IO request, the second prioritylevel being different than the first priority level.
 13. The computersystem of claim 12, wherein the processor is further configured to waitto perform the first IO request, when the performance level of the firstIO request does not meet or exceed the first target, and to perform thefirst IO request after receiving the re-allocated resources.
 14. Thecomputer system of claim 12, wherein the processor is further configuredto re-allocate resources to perform the first IO request in proportionto a limited portion of the predetermined amount of resources.
 15. Thecomputer system of claim 12, wherein the processor is further configuredperform the second IO request, when the performance level of the firstIO request meets or exceeds a second target.
 16. A physical computerstorage medium comprising a computer program product method for managingresources of a storage server, the physical computer storage mediumcomprising: computer code for receiving a first input/output (IO);computer code for dynamically assigning a first priority level to thefirst IO request, the first IO request associated with a performancelevel for an application residing on a host in communication with thestorage server; and computer code for throttling a second IO request ofa second priority level to allow at least a portion of a predeterminedamount of resources previously designated for performing the second IOrequest to be re-allocated to performing the first IO request, thesecond priority level being different than the first priority level. 17.The physical computer storage medium of claim 16, further comprising:computer code for waiting to perform the first IO request, when theperformance level of the first IO request does not meet or exceed thefirst target; and computer code for performing the first IO requestafter receiving the re-allocated resources.
 18. The physical computerstorage medium of claim 16, wherein the computer code for throttling thesecond IO request includes computer code for performing the second IOrequest with a limited portion of the predetermined amount of resources.19. The physical computer storage medium of claim 18, wherein thecomputer code for throttling the second IO request includes computercode for re-allocating resources to perform the first IO request inproportion to the limited portion of the predetermined amount ofresources used for performing the second IO request.
 20. (canceled)